Subject: Two suggestions for loop prevention.

From: Nagi Swaminathan <[email-masked]>
Date: Mon, 16 Aug 93 23:09:43 EDT

To loop prevention Group:
        
        I am a beginner in this world of Token Rings, source routing
        bridges and DLSws. I am forwarding two proposals to avoid looping
        in a network with SR bridges and DLSws which I believe will
        solve the problem(or may be I am being very naive !). 
        The following are the proposed solutions.

        Solution 1:
        -----------
        Each DLSw origin or target(grey or blue), when a broadcast frame is
        received, should subject the frame to the following check. 

        There is no LLC connection(irrespective of its state) with the
        same source MAC address, the same destination MAC address and 
        the same source SAP as indicated in the broadcast frame. If such
        connection is found the frame is not forwarded.

        I have not thought through this very well. But, seem to work.
        I thought I should bring this to the table at the earliest.
        I will send a mail again after I spent more time thinking about it.

        There may be some timing issues  which may make  this scheme useless.
        (I am not sure..). What happens if a DLSw receives a frame via a 
        bridge and then a CANUREACH  message from another DLSw.

        Solution 2:

        The main problem in avoiding looping in networks with DLSws is that
        the RIFs are not end-to-end. They get dropped by the origin
        DLSw and are restarted by the destination DLSw. 

        But, let us say destination DLSw inserts the routing field indicating 
        that it came through the IP virtual ring. This means all the broadcast
        frames passing through DLSw switch will have the virtual ring number 
        in RIF. The DLSw receiving a TEST or an XID frame will examine the
        RIF and if it found to contain the virtual ring number the frame
        will be dropped.

        Irrespective of the topology, whether it is a parallel DLSws or
        a parallel DLSw and a SR bridge, this scheme seem to solve the
        looping problem. 

        Disadvantage: Lose a hop. 

        Note: 
        ----
        This only works if there is only one virtual ring(i.e. one IP cloud).
        But, this scheme can be extended to insert into the RIF all the DLSws 
        the frames has passed through when ever a broadcast ring is injected 
        into the ring. This can be accomplished by configuring each DLSw with 
        all the virtual rings in the network. The DLSw then will look at the 
        RIF fields and leave the routing field belonging to the DLSws intact. 
        It will add its virtual ring number to the RIF and insert the frame
        into the ring. Here after, the loop avoidance just works as in source 
        routing bridge. But, more hops are lost as the frame passes through
        one or more DLSw. This will require a change to the CANUREACH message.
        The CANUREACH message now should contain the RIFs  of DLSws traversed.
        This change is backwards compatible as this will end up on the other
        side as if no DLSw is traversed on the frame path. 

        Advantage: Works in a complex network.
                   Easy to follow the DLSws traversed by sending a broadcast
                   frame. 

        Disadvantage: Each DLSw has to told about all the virtual rings.
                      Lose more hops as each DLSw takes up one hop and hence
                      does not retain the of infinite hop possibility with
                      the original DLSw(may be a severe limitation which
                      renders this scheme useless).     
                      Does not work if configured wrong.

        Regards...

        Nagi.

---

From: Choon Lee <[email-masked]>
Date: Wed, 18 Aug 1993 08:11:43 -0700

Nagi,

welcome to the loop prevention discussions.

I believe that RFC 1434 has covered the looping problem in source routing
environment. In section 3, last 2 sentences
	" ... The virtual ring segment in each Data Link Switch attached
	to a common LAN must be configured with the same ring number. This
	will prevent LAN frames sent by one Data Link Switch from being
	propagated through the other Data Link Switches."

What this group is trying to figure out now is loop prevention in a 
non source routing environment. In fact this group started out as the
"ethernet" siglet to solve that problem in the ethernet environment.

Regards,
Choon Lee
3Com Corp